MPIIT: Add support for skipJobTriggers switch for triggered job lists#77544
MPIIT: Add support for skipJobTriggers switch for triggered job lists#77544oharan2 wants to merge 2 commits intoopenshift:mainfrom
Conversation
openshift-ci
bot
added
the
approved
|
[REHEARSALNOTIFIER]
Prior to this PR being merged, you will need to either run and acknowledge or opt to skip these rehearsals. Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
/pj-rehearse periodic-ci-rhpit-interop-tests-main-weekly_trigger-tmp-interop-jobs-trigger |
|
@oharan2: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse periodic-ci-rhpit-interop-tests-main-weekly_trigger-tmp-interop-jobs-trigger |
|
@oharan2: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@oharan2: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
@oharan2 Please see https://redhat.atlassian.net/browse/INTEROP-8019?focusedCommentId=16653758 |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amp-rh, oharan2 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm cancel I'm sorry not signing off on this yet. And even if master switch approach like this is desired, there are several issue with current implementation:
|
etirta
left a comment
etirta
left a comment
There was a problem hiding this comment.
I am okay with this more streamlined implementation.
I would like to see a test using the CI Operator Emulator for a JT__TRIG_JOB_LIST that contains two entries: one with disabled: true and the other without that key.
| ) | [ | ||
| (.trigCond//[] | @json), | ||
| (.jobList//[] | @json), | ||
| (.postTask//[] | @json), | ||
| (if (.skipJobTriggers // false) then 1 else 0 end | tostring) | ||
| ] | @tsv |
There was a problem hiding this comment.
If a master switch is desired, then it should be treated as if the whole entry is undefined or excluded:
| ) | [ | |
| (.trigCond//[] | @json), | |
| (.jobList//[] | @json), | |
| (.postTask//[] | @json), | |
| (if (.skipJobTriggers // false) then 1 else 0 end | tostring) | |
| ] | @tsv | |
| ) | select(.disabled != true) | | |
| [(.trigCond//[] | @json), (.jobList//[] | @json), (.postTask//[] | @json)] | @tsv |
Remove all other changes.
| "skipJobTriggers": <true|false>, # Optional. Master switch: if true, | ||
| # skip all `jobList` triggers; `postTask` still runs. |
There was a problem hiding this comment.
First, the master switch Key name could be confused with just skipping the trigCond. Following an idiomatic approach and borrowing from other frameworks such as Systemd Units and many CI Configs, a simple Key name like disabled can be used without any ambiguity.
Second, use [...] to indicate the default value.
| "skipJobTriggers": <true|false>, # Optional. Master switch: if true, | |
| # skip all `jobList` triggers; `postTask` still runs. | |
| "disabled": <true|[false]>, # Optional. Set to `true` to skip this entry entirely. |
| 3. **(If applicable)** Check trigger conditions written by pre-Steps (e.g., resource ownership). Trigger conditions are only checked when | ||
| the bitwise mask `(trigCondFlgs & JT__TRIG_COND_EXEC_FLGS)` evaluates to non-0. If any checked trigger condition is not met, the rest | ||
| of the processing is skipped. | ||
| 4. **(If applicable)** Loop through the jobs-to-trigger JSON and trigger each Job that has `active: true` and matches the set trigger condition, if any. | ||
| This Step is skipped if `JT__SKIP_TRIG_MAIN_JOBS` is non-zero. | ||
| For each JSON list object, its `jobList` block is skipped when `skipJobTriggers` key is set to true. | ||
| If the step env `JT__SKIP_TRIG_MAIN_JOBS` is non-zero (set in the `ci-operator` config), every `jobList` item is skipped the same way. | ||
| 5. **(If applicable)** Set execution markers so the downstream processes can determine whether to execute post-Steps. Markers are only set when | ||
| the bitwise mask `(postTaskFlgs & JT__POST_TASK_EXEC_FLGS)` evaluates to non-0. | ||
| 6. Continue processing until all Jobs have been processed. |
There was a problem hiding this comment.
| 6. Continue processing until all Jobs have been processed. | |
| 3. Loop through `JT__TRIG_JOB_LIST`, skipping entries with `disabled: true`. | |
| 4. **(If applicable)** Check trigger conditions written by pre-Steps (e.g., resource ownership). Trigger conditions are only checked when | |
| the bitwise mask `(trigCondFlgs & JT__TRIG_COND_EXEC_FLGS)` evaluates to non-0. If any checked trigger condition is not met, the rest | |
| of the processing is skipped. | |
| 5. **(If applicable)** Loop through the jobs-to-trigger JSON and trigger each Job that has `active: true` and matches the set trigger condition, if any. | |
| This Step is skipped if `JT__SKIP_TRIG_MAIN_JOBS` is non-zero. | |
| 6. **(If applicable)** Set execution markers so the downstream processes can determine whether to execute post-Steps. Markers are only set when | |
| the bitwise mask `(postTaskFlgs & JT__POST_TASK_EXEC_FLGS)` evaluates to non-0. | |
| 7. Continue processing until all Jobs have been processed. |
4 participants
This PR adds an optional top-level boolean
skipJobTriggerson each job list Json object.When set to true, Gangway-API job triggering is skipped for that object’s entire
jobList; post tasks still run.Omitted or false preserves existing behavior.
trigCondFlgsmasks only control which trigger-condition steps run; they do not turn off the whole block.This gives an explicit vault-driven switch for “disable all jobs in this group” without misusing trigCond or toggling every active field.
Will be verified using the following
jobList:This job is failing on setup, so if triggered, nothing happens.